It is commonplace nowadays for a Web browser (“client”) to access content that is stored on a remote server by sending a request to the remote server using the remote server's Universal Resource Locator (URL) and receiving the content in response. Web sites associated with very popular URLs receive an extremely large volume of such requests from separate clients. In order to handle such a large volume of requests, these Web sites sometimes make use of a proxy device that initially receives requests and distributes them, according to some scheme, among multiple servers.
One such scheme attempts to distribute requests relatively evenly among servers that are connected to the proxy device. A proxy device employing this scheme is commonly called a “load balancer.” When successful, a load balancer helps to ensure that no single server in a server “farm” becomes inundated with requests.
When a proxy device receives a request from a client, the proxy device determines to which server, of many servers, the request should be directed. For example, a request might be associated with a session that is associated with a particular server. In that case, the proxy device might need to send the request to the particular server with which the session is associated.
A proxy device typically communicates with servers using a suite of protocols. For example, the proxy device may use the Internet Protocol (IP), Transport Control Protocol (TCP), and Hypertext Transfer Protocol (HTTP) in combination to communicate with a server. Some of these protocols are connection-oriented. Connection-oriented protocols typically require the negotiation of connection-related parameters between the nodes that are to be involved in the connection before the connection is “opened.” Data can be sent through the connection only after these parameters have been negotiated and the connection has been opened.
Parameter negotiation is often achieved through a “handshake” phase of a protocol. A handshake phase usually requires a significant amount of communication between the nodes. When encryption is involved, a handshake phase also may require a significant amount of processing by the nodes.
After a connection has been opened between the proxy device and a particular server, the proxy device receives a request from a client and forwards that request to the particular server through the connection. The particular server sends a response to the proxy device through the connection. The proxy device forwards the response to the client. Several requests and responses might be sent through the connection during the course of a transaction between the client and the particular server.
The proxy device acts as an intermediary throughout the communications between the client and the server. Data packets sent from the client pass through the proxy device on the way to the server. Data packets sent from the server pass through the proxy device on the way to the client. This can produce a communications “bottleneck” at the proxy device. When a single proxy device acts as an intermediary for many clients and servers, communications between those clients and servers may be delayed significantly.
Furthermore, when all communications that transpire between a client and server must pass through a proxy device, the client and the server become absolutely dependent upon the proxy device. If the proxy device fails for any reason, then the connection path between the client and the server is severed. The client and the server might not be able to resume communications at all until the proxy device becomes operational again. Even after the proxy device becomes operational again, client-to-proxy device and proxy device-to-server connections will need to be re-established via another round of time-consuming handshake phases.
In addition to causing communications between a client and a server to be interrupted, the failure of a proxy device can result in the loss of session state information that pertains to client-server sessions. Under some current approaches, session state information is stored at a proxy device rather than a server, so that if the server fails, then the proxy device can seamlessly continue the session with another server. However, viewed from one perspective, this approach merely pushes vulnerabilities from the server to the proxy device. If the proxy device suffers data loss, then all sessions that were being maintained by the proxy device may be irreparably lost also.
Some approaches attempt to compensate for this vulnerability by providing a “backup” proxy device, to which the “primary” proxy device periodically transmits updated session state information. If the “primary” proxy device fails, then the “backup” proxy device can be made, quickly, to function as a substitute for the “primary” proxy device. Unfortunately, if the “primary” proxy device fails soon before transmitting updated session state information to the “backup” proxy device, then the session state information that the “backup” proxy device will use to resume the client-server sessions may be stale, outdated, and inaccurate. The transmission of updated session state information between “primary” and “backup” proxy devices also may consume a substantial amount of network bandwidth.
Consequently, a technique that enables load-balanced communications between clients and servers, and which does not suffer from the disadvantages of some of the approaches discussed above, is desirable. The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.